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Sensor  Data  Integrity 


Executive  Summary 


This  document  constitutes  the  final  report  for  the  project  “Sensor  Data  Integrity” 
granted  by  the  Asian  Office  of  Aerospace  Research  and  Development  (USA). 

It  describes  the  data  that  was  collected  for  this  work  and  proposes  some  preliminary 
elements  of  analysis. 

In  particular,  the  documents  enclosed  present: 

•  A  presentation  of  the  UGV  System  used  to  collect  the  data,  including  all 
sensors  and  calibration  parameters 

•  A  description  of  the  data  format  and  content 

•  A  specification  of  all  datasets  provided  separately 

•  A  preliminary  analysis  of  the  performance  of  sensors  depending  on  the 
environment  conditions  and  of  the  search  for  sensor  data  integrity,  with 
perspectives  of  work  in  this  area. 


5 


Sensor  Data  Integrity: 

Final  Report 

Thierry  Peynot,  Sami  Ter  ho  and  Steven  Scheding 
ACFR,  The  University  of  Sydney 


December  2008 


Contents 


1  Presentation  of  the  System  3 

1.1  The  Argo  vehicle .  3 

1.2  The  Sensors .  4 

1.2.1  Laser  Range  Scanners .  4 

1.2.2  FMCW  Radar  .  5 

1.2.3  Visual  Camera .  5 

1.2.4  Infra-Red  Camera .  5 

1.2.5  Calibration  parameters  .  6 

1.2.6  Additional  Sensors .  11 

2  Data  Format  and  Content  12 

2.1  Files  and  Directories  Organisation  .  12 

2.2  Ascii  Log  File  Description .  13 

2.2.1  Navigation  (Localisation) .  13 

2.2.2  Range  Data  from  Lasers .  13 

2.2.3  Radar  Spectrum .  14 

2.2.4  Range  Data  from  Radar  (RadarRangeBearing) .  15 

2.2.5  Internal  Data .  16 

2.2.6  Camera  Images .  17 

3  Data  sets  18 

3.1  Environmental  conditions .  18 

3.1.1  Dust .  18 

3.1.2  Smoke .  19 

3.1.3  Rain  in  static  environment  .  19 

3.1.4  Rain  in  dynamic  environment .  19 

3.2  Static  tests .  19 

3.2.1  Day  1:  Afternoon  and  evening  .  19 

3.2.2  Day  2:  Morning  and  midday  .  28 

3.2.3  Day  2:  Morning  and  midday  -  with  added  radar  reflectors .  31 

3.2.4  Summary  of  Static  Datasets .  34 

3.3  Dynamic  tests .  35 

3.3.1  Open  area .  35 

3.3.2  Area  with  houses .  39 

3.3.3  Area  with  trees  and  water .  39 

3.3.4  Summary  of  Dynamic  Datasets .  46 


i 


CONTENTS  ii 

3.4  Calibration  Datasets .  46 

3.4.1  Cameras .  46 

3.4.2  Range  Sensors  (Lasers  and  Radar) .  47 

4  Preliminary  Analysis  48 

4.1  Case  Study .  48 

4.2  Discussion .  51 


List  of  Figures 


1.1  The  Argo  Vehicle .  3 

1.2  Argo  Sensor  Frame .  4 

1.3  Sensor,  Body  and  Navigation  frames  on  the  Argo .  7 

1.4  Relative  locations  of  sensors .  8 

3.1  Static  trial  setup  seen  from  above .  20 

3.2  Photo  of  the  static  trial  area  (Datasets  01  to  24) .  21 

3.3  Human  walking  in  the  test  area  during  a  static  test  (Dataset  03) .  23 

3.4  Static  test  with  light  dust  (Dataset  04) .  24 

3.5  Static  test  with  snroke(Dataset  07) .  26 

3.6  Static  test  with  heavy  dust  (Dataset  15) .  29 

3.7  Static  test  with  smoke  (Dataset  17) .  30 

3.8  Static  test  with  smoke  (Dataset  20) .  32 

3.9  Static  test  area  with  radar  reflectors  (Datasets  22  &  23) .  33 

3.10  Aerial  image  of  the  open  area  (on  the  left  side  of  the  path)  and  the  houses  area 

(on  the  right  side  of  the  path) .  36 

3.11  Photo  of  the  open  area  (Datasets  25  to  32)  36 

3.12  Dynamic  test  in  the  open  area  with  dust  (Datasets  30  &  31) .  37 

3.13  Dynamic  test  around  the  houses  (Datasets  33  &  34)  .  40 

3.14  Photo  of  the  area  with  trees  and  a  lake  (Datasets  35  to  40)  .  41 

3.15  Dynamic  test  around  the  lake  with  dust  (Datasets  36  to  37) .  43 

3.16  Dynamic  test  around  the  lake  with  smoke  (Dataset  38) .  44 

3.17  Dynamic  test  around  the  lake  with  simulated  rain  (Dataset  39) .  45 

4.1  Range  returned  by  the  laser  for  static  test  in  clear  conditions .  49 

4.2  Range  returned  by  radar  for  static  test  in  clear  conditions .  49 

4.3  Range  returned  by  laser  for  static  test  with  heavy  dust .  50 

4.4  Range  returned  by  radar  for  static  test  with  smoke .  50 

4.5  Range  returned  by  laser  and  radar,  for  static  test  with  rain .  51 

4.6  Filtering  dust  in  laser  data  .  52 


1 


Introduction 


This  project  presents  the  first  step  towards  developing  and  understanding  integrity  in  percep¬ 
tual  systems  for  UGVs  (Unmanned  Ground  Vehicles).  Important  issues  addressed  include; 

•  When  do  perceptual  sensors  fail,  and  why? 

•  What  combination  of  sensors  would  be  appropriate  for  a  given  operational  scenario? 

•  Can  perceptual  sensor  failure  be  reliably  detected  and  mitigated? 

Failure  is  a  very  broad  term;  it  is  hoped  that  through  this  work  a  UGV  systems  designer  will 
have  a  better  understanding  of  exactly  what  constitutes  perceptual  failure,  how  it  may  be 
designed  for  and  its  effects  remediated.  Such  failures  would  not  just  include  hardware  failure, 
but  also  adverse  environmental  conditions  (such  as  dust  or  rain),  and  algorithm  failure. 

To  begin  to  address  these  issues,  synchronised  data  have  been  gathered  from  a  representa¬ 
tive  UGV  platform  using  a  wide  variety  of  sensing  modalities.  These  modalities  were  chosen 
to  sample  as  much  of  the  electromagnetic  spectrum  as  possible,  with  the  limitation  that  the 
sensors  be  feasible  (and  available)  for  use  on  UGVs.  A  preliminary  analysis  has  then  been 
performed  on  the  data  to  ascertain  the  prime  areas  of  competence  of  the  sensors,  and  the 
combination  of  sensors  most  promising  for  a  set  of  representative  UGV  scenarios. 

Further  work  (not  contained  in  this  document)  would  develop  the  theoretical  framework 
for  sensor  data- fusion  and  on-line  integrity  monitoring  for  use  in  UGV  perceptual  systems.  In 
particular,  the  latter  would  provide  an  on-line  “quality”  evaluation  of  the  environment  per¬ 
ception  and/or  the  environment  modeling  based  on  that  perception  [6],  with  sensor /modeling 
fault  detection  and  isolation  [5,  4],  This  would  constitute  a  susbtantial  benefit  for  UGV 
navigation  efficiency,  robustness  and  safety. 

This  document  is  structured  as  follows:  the  first  chapter  presents  the  system  used  to 
gather  the  data,  in  particular  the  sensors  involved  (and  their  characteristics).  The  second 
chapter  presents  the  datasets  collected,  listing  the  kind  of  environment,  the  conditions  and 
the  relevant  information  to  be  able  to  exploit  the  data.  Finally,  the  third  chapter  gives  a 
preliminary  analysis  of  sensor  data  integrity,  based  on  the  gathered  data. 
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Chapter  1 


Presentation  of  the  System 


This  chapter  presents  the  system  used  to  collect  the  data.  It  is  composed  of  a  ground  vehicle 
called  the  Argo,  equipped  with  various  sensors. 


1.1  The  Argo  vehicle 


The  vehicle  used  to  collect  the  data,  the  CAS1  Outdoor  Research  Demonstrator  (CORD),  is 
an  8  wheel  skid-steering  vehicle  with  no  suspension  (see  figure  1.1),  which  turns  thanks  to 
pressure  controlled  brakes  on  both  sides.  It  has  a  petrol  engine,  with  a  12V  alternator,  and 
a  24V  alternator  to  provide  power  to  the  computers  and  sensors  on  board. 


Figure  1.1:  The  Argo  Vehicle 


For  the  purpose  of  this  work,  it  has  been  equipped  with  multiple  sensors,  described  in  the 
following  section. 

XCAS  stands  for  Centre  for  Autonomous  Systems 
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1.2  The  Sensors 


All  exteroceptive  sensors  are  mounted  on  a  sensor  frame  on  top  of  the  vehicle,  as  can  be  seen 
on  figures  1.1  and  1.2. 


Radar 


LaserStarboard 


LaserVertical 


Visual 

Camera 


IR  Camera 


LaserPort 


LaserHoriz  ontal 


Figure  1.2:  Argo  Sensor  Frame 


1.2.1  Laser  Range  Scanners 

Four  laser  range  scanners  are  used.  Two  of  them  are  SICK  LMS  291,  they  are  mounted  at 
the  center  of  the  sensor  frame.  The  two  others  are  SICK  LMS  221  mounted  on  both  sides 
of  that  frame.  The  approximate  configuration  of  these  lasers,  together  with  the  names  that 
will  be  used  in  the  rest  of  this  document,  are  the  following2  (see  Figure  1.2.  Note  that  roll 
corresponds  to  a  rotation  around  axis  X  and  pitch  to  a  rotation  around  axis  Y): 

1.  LaserHorizontal:  centered  on  the  sensor  frame,  slightly  pointing  down  to  the  ground  (a 
few  degrees  of  pitch),  zero  roll3. 

2.  LaserVertical:  centered  on  the  sensor  frame,  with  90  degrees  roll  (thus  scanning  verti¬ 
cally),  zero  pitch. 

3.  LaserPort :  located  on  the  Port  side  of  the  vehicle,  this  laser  is  slightly  pointing  down 
to  the  ground  (a  few  degrees  of  pitch,  less  than  for  the  LaserHorizontal) ,  zero  roll. 

2see  Section  1.2.5  on  calibration  for  more  precise  estimation  of  their  positions  on  the  vehicle 

3Note  that  this  laser  looks  flipped  over  on  fig.  1.2  (i.e.  180  deg.  roll).  However,  this  is  accounted  for  in  the 
process  of  data  acquisition,  thus  it  should  be  considered  as  with  a  zero  roll. 
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4.  Laser  Starboard :  located  on  the  Starboard  side  of  the  vehicle,  this  laser  is  intended  to 
have  zero  pitch  and  zero  roll. 

Characteristics  and  Nominal  Performances 

All  four  lasers  were  set  to  acquire  data  in  the  following  mode: 

•  0.25  degree  resolution 

•  cm  accuracy4 

•  180  degree  angular  range5 

1.2.2  FMCW  Radar 

This  is  a  94GHz  Frequency  Modulated  Continuous  Wave  (FMCW)  Radar  (custom  built  at 
ACFR  for  environment  imaging).  Maximum  rotation  of  scan  head:  360  degrees  at  approxi¬ 
mately  8Hz,  lKHz  sample  rate. 

•  Range  resolution:  0.2m. 

•  Maximum  range:  40m. 

1.2.3  Visual  Camera 

The  Visual  camera  (as  opposed  to  the  Infra-Red  Camera)  is  a  Prosilica  Mono-CCD  megapixel 
Gigabit  Ethernet  camera,  pointing  down  (a  few  degrees  of  pitch). 

Characteristics  and  Nominal  Performances 

•  Image  Pixel  Dimensions:  1360  x  1024 

•  Resolution:  72  x  72  ppi  (pixels  per  inch) 

•  RGB  Colour,  depth:  8  bits 

•  Nominal  Framerate:  15  images  per  second  in  static 6  datasets,  10  images  per  second  in 
dynamic  datasets  (unless  specified  differently). 

1.2.4  Infra-Red  Camera 

Raytheon  Thermal- eye  2000B.  The  images  are  acquired  through  a  frame  grabber  providing 
digital  images  of  size  640  x  480  pixels. 

4except  for  the  cameras  to  lasers  calibration  dataset,  where  the  mm  accuracy  mode  was  used  for  more 
precision,  but  limiting  the  maximum  range  to  8m  and  the  angular  range  to  100  degrees. 

5except  for  the  cameras  to  lasers  calibration  dataset,  for  which  a  100  degree  angular  range  was  used. 

6 see  section  3.2 
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Characteristics  and  Nominal  Performances 

•  Image  Pixel  Dimensions  of  complete  image:  640  x  480.  In  practice,  though,  the  images 
are  usually  clipped  to  511  x  398  to  remove  useless  black  bands  on  the  sides.  Actual 
sensor  size:  320  x  240. 

•  Average  Framerate:  12.5  images  per  second  (unless  specified  differently). 

•  Spectral  response  range:  7  —  14 fim. 

1.2.5  Calibration  parameters 

The  spatial  transformations  between  sensors  and  reference  frames  have  been  estimated  using 
thorough  calibration  methods.  The  frames  used  are  illustrated  on  Figure  1.3.  They  are 
named: 

•  Navigation  frame:  (fixed)  global  frame  defined  by  the  three  axis:  Xn  =  North,  Yn  = 
East  and  Zn  =  Down  in  which  positions  are  expressed  in  UTM  coordinates  (Universal 
Transverse  Mercator). 

•  Body  frame:  frame  linked  to  the  body  of  the  vehicle,  its  centre  being  located  at  the 
centre  of  the  IMU  (Inertial  Measurement  Unit),  approximately  at  the  centre  of  the 
vehicle.  The  axis  are:  Xb  pointing  towards  the  from  of  the  vehicle,  Yh  pointing  to  the 
Starboard  side  of  the  vehicle,  and  Zh  pointing  down. 

•  Sensor  frame:  frame  linked  to  a  particular  sensor.  It  is  defined  in  a  similar  way  as 
the  previous  one  (i.e.  Xs  forward,  Ys  starboard,  Zs  down),  but  centered  on  the  sensor 
considered. 

Note  that  in  the  rest  of  the  document  Navigation  (or  localisation)  will  correspond  to  the 
global  positioning  of  the  Body  frame  in  the  Navigation  frame. 

The  measured  distances  between  sensors  are  illustrated  in  figure  1.4.  Note  that  an  actual 
process  of  calibration  usually  provides  better  estimations  of  the  real  transformations  between 
sensors.  However  these  measured  values  are  good  initial  estimates  for  calibration  processes 
(and  they  were  actually  used  as  such  in  this  work). 

Two  categories  of  calibration  have  been  made: 

•  Range  Sensor  Calibration,  to  estimate  the  transformations  between  the  frame  associated 
to  each  range  sensor  (laser  scanner  or  radar)  and  the  Body  frame. 

•  Camera  Calibration,  to  estimate  the  intrinsic  (geometric)  parameters  of  each  camera, 
and  the  extrinsic  transformations  between  cameras  and  lasers. 


Range  Sensor  Calibration 

The  estimation  of  the  transformations  between  the  frame  associated  to  each  range  sensor 
(laser  scanner  or  radar)  and  the  Body  frame  was  made  using  a  technique  detailed  in  [1,  8]. 
For  that  purpose,  a  dataset  was  acquired  in  an  open  area  with  flat  ground  and  key  geometric 
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navigation  (n) 


Figure  1.3:  Sensor,  Body  and  Navigation  frames  on  the  Argo 


features  such  as  a  vertical  metallic  wall,  two  vertical  poles  with  high  reflectivity  for  lasers, 
and  two  vertical  poles  for  the  radar  (see  section  3.4.2). 

The  results  of  this  calibration  are  the  estimation  of  the  3  rotation  angles  ( RollX ,  PitchY 
and  YawZ )  and  3  translation  offsets  {dX ,  dY ,  dZ)  from  the  Body  frame  to  the  Sensor  frame. 
All  angles  will  be  expressed  here  in  degrees  for  convenience  and  distances  in  metres. 

The  following  table  shows  the  results  obtained  after  combined  calibration  of  all  four  range 
sensors,  i.e.  Laser  Horizontal  (or  LaserH ),  LaserVertical  (or  LaserV ),  LaserPort  (or  LaserP ), 
Laser  Starboard  (or  LaserS)  and  the  Radar.  Common  features  are  used  for  all  sensors.  It  is 
recommended  to  use  these  calibration  results  when  combining  the  information  from  groups 
of  these  sensors. 


Transformations  Body  Frame  to  Sensor  Frame: 


Sensor 

RollX 

PitchY 

YawZ 

dX 

dY 

dZ 

LaserH 

-0.732828 

-8.586863 

-1.631319 

0.108987 

0.008302 

-0.919726 

LaserV 

88.562966 

-0.118007 

-1.123153 

-0.000291 

-0.082272 

-1.126802 

LaserP 

-0.500234 

-2.616210 

-1.805911 

0.190857 

-0.548777 

-0.763776 

LaserS 

-0.608178 

-0.431051 

-2.349991 

0.198663 

0.534253 

-0.849538 

Radar 

-0.151571 

191.161703 

173.278081 

-0.025753 

-0.047174 

-1.399104 

Visual  Camera  Calibration 

Intrinsic  parameters  The  intrinsic  calibration  of  each  camera  was  made  using  the  Camera 
Calibration  Toolbox  for  Mat.lab  [2] . 
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Figure  1.4:  Distances  between  sensors  in  the  ( y,z )  plane,  in  cm.  Note  that  the  dashed 
lines  are  meant  to  go  through  the  centre  of  the  sensors  (despite  any  other  impression  due  to 
perspective  of  the  original  picture) . 
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The  following  is  the  content  of  the  Calib_Results .m  file  exported  by  the  toolbox,  that 
describes  the  output  of  the  calibration  process  in  Matlab  language: 

*/. —  Focal  length: 

fc  =  [1023.094873083798120;  1020.891695892045050]; 

*/. —  Principal  point : 

cc  =  [643.139025535655492;  482.455417980580421]; 
l —  Skew  coefficient: 
alpha  c  =  0.000000000000000; 

*/. —  Distortion  coefficients: 

kc  =  [-0.218504818968279;  0.138951469767851; 

-0.000755791245166;  0.000175881419552;  0.000000000000000]; 
l —  Focal  length  uncertainty: 

/  c  error  =  [1.240637187529808;  1.220702756108720]; 

*/. —  Principal  point  uncertainty: 
cc  error  =  [1.338561085455541;  1.362301725972313]; 
l —  Skew  coefficient  uncertainty: 
alpha-C-error  =  0.000000000000000; 

*/. —  Distortion  coefficients  uncertainty: 
kc_error  =  [0.001808042132202;  0.003689996468947; 

0.000207366100112;  0.000221355286767;  0.000000000000000]; 

*/. —  Image  size: 
nx  =  1360; 
ny  =  1024; 

The  reader  is  invited  to  consult  the  toolbox  web  site  [2]  for  more  details  on  these  parameters. 
These  output  files  from  the  calibration  toolbox  are  included  in  the  datasets. 

Note  that  of  the  93  images  selected  for  the  calibration  process,  74  were  actually  used 
in  the  final  optimisation  process  (see  the  file  Calib_Results .m  for  details).  The  pixel  error 
obtained  for  this  calibration  is: 

Pixel  error:  err  =  [  0.19209  0.20252  ] 

Extrinsic  parameters  (position  of  camera  with  respect  to  lasers)  The  extrinsic 
transformations  between  each  camera  and  each  laser  was  made  using  a  method  adapted  from 
[7].  It  uses  the  ouput  of  the  Matlab  Camera  Calibration  Toolbox  to  estimate  the  positions 
and  orientations  of  the  planes  corresponding  to  the  checker  board  visible  in  the  images. 
These  positions  are  compared  with  the  positions  of  the  laser  points  hitting  this  board.  An 
optimisation  process  gives  an  estimation  of  the  position  of  the  laser  range  scanner  with  respect 
to  the  camera. 

The  following  gives  the  three  translations  (SXC,  5YC  and  5ZC )  and  three  rotations  ( 4>XC , 
cj)Yc  and  <pZc)  enabling  the  placement  of  a  point  with  original  coordinates  in  the  camera 
frame  (using  the  convention  used  for  the  Matlab  Toolbox:  +XC  to  the  right,  +YC  down,  +ZC 
forward)  into  the  sensor  frame  linked  to  each  laser.  Distances  are  expressed  in  metres  and 
angles  in  degrees. 


LaserHorizontal  to  Visual  camera: 


5AC 

5TC 

<t>xc 

4>Yc 

<t>Zc 

0.4139 

-0.2976 

-0.0099 

-4.7341 

-0.3780 

-0.4230 
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LaserVertical  to  Visual  camera:' 


IR  Camera  Calibration 

Intrinsic  parameters  The  intrinsic  calibration  of  this  camera  was  also  made  using  the 
Camera  Calibration  Toolbox  for  Matlab  [2] . 

The  following  is  the  content  of  the  Calib_Results  .m  file  exported  by  the  toolbox,  that 
describes  the  output  of  the  calibration  process  in  Matlab  language: 

*/. —  Focal  length: 

fc  =  [790.131547995049573;  826.825751328548790]; 

*/. —  Principal  point : 

cc  =  [328.685823692670340;  164.376489311973216]; 

l —  Skew  coefficient: 

alpha.c  =  0.000000000000000; 

l —  Distortion  coefficients: 

kc  =  [-0.466898225930376;  0.246094535921152; 

0.011203533644424;  -0.005108186223306;  0.000000000000000]; 

*/. —  Focal  length  uncertainty: 

fc.error  =  [5.782890597916310;  6.015102913624340]; 

*/. —  Principal  point  uncertainty: 

cc.error  =  [9.426499879136482;  10.292926183444356]; 

l —  Skew  coefficient  uncertainty: 

alpha.c.error  =  0.000000000000000; 

l —  Distortion  coefficients  uncertainty: 

kc-error  =  [0.026759198529728;  0.152385380407985 

0.002604709115691;  0.002243445036632;  0.000000000000000]; 

*/. —  Image  size: 
nx  =  640; 
ny  =  480; 

Extrinsic  parameters  (position  of  cameras  with  respect  to  lasers)  The  same  oper¬ 
ations  as  for  the  visual  camera  were  applied  to  determine  the  transformations  between  the 
IR  camera  frame  and  each  laser. 

7Note  that  this  transformation  was  computed  by  combining  the  previous  transformation  LaserHorizontal 
to  camera  with  the  relative  transformation  of  the  two  lasers  found  in  the  Range  Sensor  Calibration  above,  as 
the  direct  calibration  method  would  not  provide  satisfying  results. 
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Note  that  the  images  and  correspondings  laser  scans  which  were  used  for  this  calibration 
are  available  in  the  directory  named  IRcameraCalibration  (see  section  3.4.1).  The  images 
in  this  dataset  are  full  resolution  640  x  480  as  provided  by  the  frame  grabber,  unlike  the 
IR  images  in  the  other  datasets  which  are  clipped  to  keep  only  the  part  containing  actual 
information. 

1.2.6  Additional  Sensors 

Other  sensors  available  on  the  Argo  platform  that  will  provide  useful  information  are: 

•  Novatel  SPAN  System  (Synchronized  Position  Attitude  &  Navigation)  with  a  Honey¬ 
well  IMU  (Inertial  Measurement  Unit).  This  usually  provides  a  2cm  RTK  solution  for 
localisation, 

•  Wheel  encoders,  measuring  wheel  angular  velocities, 

•  Brakes  sensors  (position  and  pressure), 

•  Engine  and  gearbox  rotation  rate  sensors. 


8Note  that  this  transformation  was  computed  by  combining  the  previous  transformation  LaserHorizontal 
to  camera  with  the  relative  transformation  of  the  two  lasers  found  in  the  Range  Sensor  Calibration  above. 


Chapter  2 

Data  Format  and  Content 


This  chapter  presents  the  format  of  the  data  provided.  Section  2.1  describes  the  organisation 
of  directories  and  files.  Section  2.2  then  precisely  defines  the  format  of  the  content  of  each 
file  containing  data.  Note  that  in  the  rest  of  the  document  the  Typewriter  font  will  be  used 
to  designate  names  of  directories  or  files  and  text  written  in  ascii  files. 

2.1  Files  and  Directories  Organisation 

Each  dataset  has  its  directory  containing  all  data  from  all  sensors.  It  usually  corresponds  to 
a  particular  test  (specific  environment  and  conditions).  Its  name  is  composed  of  a  number 
(corresponding  to  the  chronological  order  of  the  data  acquisition)  and  a  string  roughly  de¬ 
scribing  the  environment  and  conditions1.  An  example  is:  04-StaticLightDust  for  a  static 2 
test  in  the  presence  of  light  dust. 

A  dataset  directory  usually  contains  eleven  sub-directories  corresponding  to  the  differents 
sensors  involved  (or  type  of  data,  see  section  1.2);  namely: 

•  LaserHorizontal 

•  LaserPort 

•  LaserStarboard 

•  LaserVertical 

•  Nav 

•  Payload 

•  RadarRangeBearing 

•  RadarSpectrum 

•  VideoIR 

•  VideoVisual 

xa  much  more  complete  description  is  provided  into  each  directory  though 
2  See  the  more  precise  definition  of  static  and  dynamic  test  in  chapter  3. 
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2.2  Ascii  Log  File  Description 

This  section  describes  the  content  of  the  ascii  files  that  can  be  found  in  each  of  the  directories 
mentioned  above. 

Note  that  in  all  logged  ascii  files,  the  default  units  will  be  metres  for  all  distances  and 
radians  for  all  angles  (except  for  the  Radar  Spectrum  data) .  Consequently,  anywhere  units  are 
not  clearly  specified,  metres  and  radians  prevail.  All  files  start  with  a  time  stamp,  expressed 
in  seconds,  which  corresponds  to  the  Unix  time. 

Files  contain  one  data  sample  (complete)  message  per  line.  The  first  columns  of  all  ascii 
file  have  the  general  form: 


*<timestamp>  TEXT.TYPE  data 

where  TEXT.TYPE  is  a  string  describing  the  type  of  data  written  on  this  line  (e.g.  NAV_DATA 
for  navigation  data)  and  data  is  the  actual  data  from  the  sensor,  written  on  as  many  columns 
as  needed. 

More  specifically,  the  next  sections  describe  the  actual  content  of  each  type  of  file  for  each 
type  of  sensor  or  data.  They  will  first  indicate  the  name  of  the  directory  where  the  data  can 
be  found  and  then  illustrate  the  content  by  a  table. 

2.2.1  Navigation  (Localisation) 

Name  of  directory:  Nav. 

The  ascii  data  are  contained  in  a  file  named  NavQAsciiData.txt.  The  content  of  each  line 
of  this  file  is  described  in  the  following  table.  It  corresponds  to  the  global  localisation  of  the 
vehicle  ( Body  frame )  expressed  using  the  UTM  coordinate  system,  in  metres  and  radians. 


Column: 

1 

2 

3 

4 

5 

6 

7 

8 

Data  : 

*<timestamp> 

NAVJDATA 

North 

East 

Down 

dNorth 

dEast 

dDown 

Column: 

9 

10 

11 

12 

13 

14 

15-158 

Data: 

RollX 

PitchY 

YawZ 

dRoll 

dPitch 

dYaw 

cid 

where  Cij,  ( i,j )  €  [1,1 2] 2  are  the  elements  of  the  covariance  matrix  describing  the  co- 
variances  between  the  12  elements  appearing  in  columns  3  to  14.  Note  that  this  matrix  is 
written  in  rows:  the  whole  row  number  1  first,  then  row  2  etc. . .  In  other  words,  it  is  written 
as:  CYi,  Ci, 2  •  •  • ,  Ci, 12,  C24,  ■  •  •  Ci2,i2- 

2.2.2  Range  Data  from  Lasers 

This  concerns  the  directories  of  the  four  lasers,  namely: 

•  LaserHorizontal 

•  LaserVertical 

•  LaserPort 


•  LaserStarboard 
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In  each  of  these  directories,  the  ascii  data  are  contained  in  a  file  named  RangeBearingQAsciiData .  txt. 
The  content  of  each  line  of  this  file  is  described  in  the  following  table.  Each  line  of  the  file 
typically  shows  the  result  of  a  2D  scan  of  180  degrees  with  an  increment  of  1  degree.  The  first 
part  of  the  line  gives  parameters  describing  this  scan  and  the  second  part  gives  the  actual 
range  values  returned  by  the  laser  sensor.  4  successive  scans  (i.e.  4  lines  in  the  file),  with 
starting  angles  each  time  incremented  by  0.25  degree,  will  finally  provide  a  full  180  degree 
wide  and  0.25  degree  resolution  scan. 


Column: 

1 

2 

3 

4 

Data  : 

*<timestamp> 

RANGE .DATA 

StartAngleRads 

AnglelncrementRads 

Column: 

5 

6 

7 

8  —  end 

Data  : 

EndAngleRads 

RangeUnitType 

NScans 

Range; 

where: 


•  StartAngleRads  ( double )  is  the  value  in  radians  of  the  first  angle  of  the  current  scan 
(i.e.  the  one  described  on  the  current  line  of  the  file). 

•  AnglelncrementRads  ( double )  is  the  difference  of  angle  between  two  successive  scan 
values  (namely  Range,-  and  Range,:+1),  in  radians. 

•  EndAngleRads  ( double )  is  the  value  in  radians  of  the  last  angle  of  the  current  scan  (i.e. 
the  current  line). 

•  RangeUnitType  is  an  integer  showing  the  unit  for  the  range  values  that  follow  in  the 
line  (Range,).  The  possible  integers  and  their  meanings  are  as  follow: 


-  1: 

mm 

-  2: 

cm 

3: 

m 

-  4: 

km 

•  NScans  is  the  number  N  of  scan  values.  Note  that:  end  =  8  +  (NScans  —  1) 

•  Range,-  with  j  6  [1,  NJ  are  the  actual  range  values  for  each  angle  of  the  current  scan 
(the  unit  being  determined  by  RangeUnitTypeEnum). 

2.2.3  Radar  Spectrum 

The  directory:  RadarSpectrum  contains  the  radar  spectrum,  described  as  the  bins  of  a  Fast 
Fourier  Transform  (FFT).  The  ascii  data  are  contained  in  a  file  named  HSR.ScalarPointsl  .txt. 
The  content  of  each  line  of  this  file  is  described  in  the  following  table: 


Col.: 

1 

2 

3  to  end 

Data: 

*<timestamp> 

Angle(degrees) 

Reflectivity; 

where: 


Angle  is  the  angle,  in  degrees,  of  the  bins  of  this  line. 
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•  Ref  lectivity,-  with  i  £  [1,1V]  (IV  being  the  total  number  of  bins  on  the  line)  are  the 
reflectivity  of  each  bin.  Each  of  these  bins  correspond  to  a  different  range,  with  can  be 
determined  using  the  following. 

First,  note  the  following  parameters,  obtained  after  intrinsic  calibration  of  the  radar  scanner: 

•  the  Sample  Frequency  is  sampleFreq  =  125000077.2. 

•  the  frequency  per  metre  is:  hertzPerM  =  4336.384 Hz/m.. 

•  the  range  offset  is:  offsetM  =  —0.3507m. 

This  means  that  the  range  associated  to  a  particular  bin  (namely  binRange )  can  be  found  by 
calculating: 


frequencyH  zPerBin  =  sampleFreq  /  (2  *  number  Of  Bins) 
rangeMPerBin  =  frequencyH  zPerBin/ hertzPerM  (2-1) 

binRange  =  bin  x  rangeMPerBin  +  offsetM 

where  bin  represents  the  bin  number  (i.e.  column  number  in  the  file  -  2,  starting  with  1)  and 
binRange  is  the  range  associated  to  this  particular  bin. 

2.2.4  Range  Data  from  Radar  (RadarRangeBearing) 

This  concerns  the  directory  named  RadarRangeBearing.  It  contains  range  information  from 
the  radar,  which  is  estimated  from  the  spectrum.  The  ascii  data  are  contained  in  a  file  named 
RangeBearingQAsciiData.txt.  Its  format  is  very  similar  to  the  laser  files  seen  above,  only 
with  reflectivity  information  in  addition  to  the  range  information.  The  content  of  each  line 
of  the  file  is  described  in  the  following  table: 


Col.: 

1 

2 

3 

4 

Data: 

*<timestamp> 

RANGEJtEFLECTIVITYJDATA 

StartAngleRads 

AnglelncrRads 

Col.: 

5 

6 

7 

8 

Data: 

EndAngleRads 

RangeUnitType 

NScans=l 

Range 1 

Col.: 

9 

Data: 

Ref lectivity1 

where: 


•  StartAngleRads  (double)  is  the  value  in  radians  of  the  first  angle  of  the  current  scan 
(i.e.  the  one  described  on  this  line  of  the  file). 

•  AnglelncrRads  (double)  is  the  difference  of  angle  (increment)  between  two  successive 
scan  values.  AnglelncrRads  =  0  in  this  file,  as  there  is  only  one  range  value  per  line. 

•  EndAngleRads  (double)  is  the  value  in  radians  of  the  last  angle  of  the  current  line.  In 
practice,  in  this  file,  EndAngleRads  =  AnglelncrRads. 

•  RangeUnitType  is  an  integer  showing  the  unit  for  the  range  values  that  follow  in  the 
line.  The  possible  integers  and  their  meanings  are  as  follow: 


—  1:  mm 
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-  2: 

cm 

-  3: 

m 

-  4: 

km 

•  NScans  is  the  number  of  scan  values.  Here  NScans=l  (one  range  value  per  line  only). 

•  Range  1  is  the  actual  range  value  for  the  current  angle  of  the  current  scan  (the  unit  being 
determined  by  the  value  of  RangeUnitTypeEnum). 

•  Ref  lectivity1  is  the  reflectivity  of  this  current  bin. 

The  range  and  reflectivity  information  contained  in  this  file  are  extracted  from  the  FFT 
(see  section  2.2.3)  by  searching  for  the  peak  of  highest  reflectivity.  The  corresponding  range 
that  can  be  calculated  by  direct  application  of  equation  (2.1)  is  limited  to  the  resolution 
of  the  discrete  FFT:  0.28m.  Thus,  to  obtain  a  higher  accuracy,  a  quadratic  interpolation  is 
performed  on  the  peak  processed  from  the  signal:  the  interpolated  range  is  the  range  obtained 
for  the  maximum  point  of  the  quadratic  polynomial  that  is  fitted  to  the  three  points  of  the 
FFT  spectrum  defining  the  peak  (see  [3]  for  more  details). 

2.2.5  Internal  Data 

Name  of  directory:  Payload. 

This  concerns  internal  data  from  the  vehicule,  such  as  status  of  braking,  wheel  velocity 
etc. . .  Note  that  this  category  of  data  is  only  relevant  for  the  dynamic  tests  (moving  vehi¬ 
cle).  Thus  they  shall  be  found  only  in  the  directories  of  this  category  of  datasets.  The  ascii 
data  are  contained  in  a  file  named  PayloadDatal.txt.  The  regular  format  of  each  line  of 
this  file  is  still: 

*<timestamp>  TEXT.TYPE  data 

with  TEXT.TYPE  having  various  possible  values.  These  values  and  the  corresponding  line  for¬ 
mat  and  content  of  data  are  described  in  the  table  below.  Note  that,  as  previously,  the  first 
line  of  this  table  shows  the  column  number. 


i 

2 

3 

4 

*<timestamp> 

SERVCLSETPOINT_DATA 

chokePosition 

throttlePosition 

*<timestamp> 

VEL  □  C I T  Y_TURN  _RATE  _D  AT  A 

velocity 

turnRate 

*<timestamp> 

SENS0R_DATA 

sensor 

value 

1 

2 

3 

4 

*<timestamp> 

BRAKE_DATA 

left  Br  akePosition 

rightBrakePosition 

5 

6 

leftBrakePressure 

rightBrakePressure 

1 

2 

3 

4 

*<timestamp> 

ACTUATOR_SETPOINT_DATA 

desiredChoke 

desiredThrottle 

5 

6 

desiredLeft  Brake 

desiredRightBrake 

When  TEXT_TYPE  =  SENSORJDATA,  sensor  is  an  integer  referring  to  a  particular  internal  sen¬ 
sor.  The  possibilities  and  the  corresponding  meaning  for  value  are  illustrated  in  the  following 
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table: 


sensor 

value  (unit) 

0 

Engine  Rotation  Rate  (RPM) 

1 

Gearbox  Rotation  Rate  (RPM) 

2 

12V  Battery  Voltage  (V) 

3 

24V  Battery  Voltage  (V) 

4 

Left  Wheel  Angular  Velocity  (rad/s) 

5 

Right  Wheel  Angular  Velocity  (rad/s) 

Note  that  these  data  are  provided  for  information,  but  a  model  of  the  vehicle  would  be 
needed  to  actually  make  the  BRAKEJDATA,  ACTUATOR_SETPOINT_DATA  and  the  RPM  information 
really  useful  for  the  reader.  It  is  recommended  to  contact  the  authors  in  that  case. 

2.2.6  Camera  Images 

Two  directories  concern  camera  images:  one  for  the  Infra-Red  Camera  (VideoIR)  and  one 
for  the  Visual  Camera  (VideoVisual).  Both  contain  the  same  kind  of  data: 

•  One  ascii  file  named  VideoLogAscii.txt,  with  the  following  format: 


Column: 

1 

2 

3 

Data: 

*<timestamp> 

VISION_FRAME 

<f ilename> 

•  One  directory  Images  containing  all  the  bmp  images  (as  files)  provided  by  the  camera. 
Those  files  have  the  names  described  in  the  VideoLogAscii.txt  file.  Note  that  this 
name  is  formed  by  the  prefix  ’Image’  followed  by  a  timestamp  (where  the  between 
seconds  and  fractions  of  seconds  has  been  replaced  by  a  plus  the  extension  ’  .bmp'. 


Chapter  3 

Data  sets 


There  are  two  types  of  datasets.  In  the  static  ones  the  vehicle  is  stationary  and  the  sensors 
acquire  data  always  from  the  same  area.  The  area  contains:  features  with  known  character¬ 
istics  and  dimensions  inside  an  identified  frame,  and  objects  and  equipment  used  for  creating 
the  environmental  conditions  (e.g.  a  compressor  and  a  water  pump),  outside  of  the  frame. 
In  the  dynamic  datasets  the  vehicle  moves  around  the  test  area,  which  usually  contains  the 
same  equipment  as  mentioned  before,  plus  a  car  (from  which  the  UGV  was  operated). 

The  purpose  of  the  static  datasets  was  to  acquire  data  in  different  conditions  but  with  the 
same  features,  to  enable  a  comparison  of  the  effects  of  different  environmental  conditions. 

Note  that  static  or  dynamic  will  refer  to  the  state  of  the  vehicle,  not  the  status  of  the 
environment,  which  can  be  considered  as  static  except  if  the  presence  of  a  moving  element 
such  as  a  human  is  present. 

The  beginning  and  ending  times  of  the  datasets  are  expressed  in  three  formats.  The  first 
column  shows  the  Unix  time,  that  is,  seconds  after  midnight  UTC  of  January  1,  1970.  The 
leap  seconds  are  not  counted  in  this  convention.  The  second  column  shows  the  UTC  time. 
UTC  stands  for  Universal  Timing  Convention,  and  is  equivalent  to  the  Greenwich  Meridian 
Time  (GMT).  The  third  column  shows  the  local  AEDT  time  in  the  test  site.  AEDT  stands 
for:  Australian  Eastern  Daylight  Saving  Time. 

As  the  data  acquisition  was  made  with  several  (synchronised)  computers,  sensor  data 
logging  does  not  necessarily  start  at  the  exact  same  time  for  all  sensors.  Thus,  for  convenience, 
the  Start  and  End  time  correspond  respectively  to  the  earliest  and  the  latest  time  of  the 
dataset  when  all  data  from  all  sensors  are  available. 

The  next  section  describes  each  type  of  conditions  that  appear  in  the  datasets. 

3.1  Environmental  conditions 

The  simulated  environmental  conditions  include  dusty  environment,  smoke,  rain,  and  clear 
environment  without  any  adverse  environmental  conditions. 

3.1.1  Dust 

The  dust  was  generated  by  blowing  air  to  dusty  soil.  The  blower  was  a  high-power  air 
compressor  with  a  flexible  tube  for  directing  the  air.  Some  of  the  datasets  were  gathered 
in  areas  where  the  soil  was  naturally  very  dusty.  In  these  cases  the  dust  was  generated  by 
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blowing  the  air  to  the  ground  near  the  vehicle.  In  the  other  cases  the  dusty  soil  was  collected 
and  piled  near  the  actual  test  site,  and  the  air  was  blown  to  the  pile  to  generate  a  cloud  of 
dust. 

3.1.2  Smoke 

Orange  smoke  was  generated  with  smoke  bombs  that  worked  for  about  one  minute.  The 
bomb  was  held  by  an  assistant,  choosing  their  position  so  that  the  wind  carried  the  smoke 
towards  the  vehicle.  Sometimes  the  direction  of  the  wind  varied,  so  the  assistant  would  move 
to  compensate. 

3.1.3  Rain  in  static  environment 

In  the  static  tests  the  rain  was  generated  with  sprinklers  attached  to  the  top  of  a  frame 
defining  the  test  area  (see  figure  3.2).  This  frame  covered  an  area  being  9.3  meters  long  and 

4.3  meters  wide.  The  water  was  stored  in  a  tank  equipped  with  a  pump  to  bring  the  water 
to  the  sprinkler  system.  This  device  is  visible  on  the  right  side  of  the  frame  and  the  vehicle. 

3.1.4  Rain  in  dynamic  environment 

In  the  dynamic  tests  the  rain  was  generated  with  the  same  tank  as  in  the  static  tests,  but 
instead  of  sprinklers,  the  rain  was  simulated  by  spraying  the  water  with  a  hand-held  hose 
pointed  at  the  vehicle’s  working  area. 

3.2  Static  tests 

In  the  static  tests  the  vehicle  was  standing  still  and  imaging  an  area  with  known  features, 
inside  the  sprinkler  frame  used  for  generating  the  rain.  These  objects  were  generally  chosen 
to  be  easily  detected  by  the  sensors  in  clear  conditions.  Most  of  them  are  artificial  and  of 
simple  geometry  (e.g.  box  or  pole)  and  their  dimensions  are  provided:  figure  3.1  shows  a 
drawing  of  this  area  with  location  of  the  features.  However,  a  branch  of  tree  (attached  to  a 
metal  bar  stuck  into  the  ground)  was  also  set  in  the  test  area  to  have  a  natural  feature.  The 
elements  of  figure  3.1  are  also  listed  in  the  table  3.1  for  more  details.  The  positions  of  these 
features  were  chosen  so  that  every  sensor  (in  particular  the  2D  laser  scanners)  can  see  at  least 
some  of  them  and  the  objects  are  distributed  over  the  area. 

The  framerate  of  the  visual  camera  in  this  series  of  tests  was  15  frames  per  second,  except 
in  the  first  dataset  where  the  framerate  was  10  frames  per  second. 

The  vehicle  was  facing  south.  Therefore  the  sun  was  either  behind  or  on  the  side  of  the 
vehicle.  As  the  data  sets  were  collected  in  Australia,  sun  shines  from  the  north  in  the  middle 
of  the  day.  Note  that  in  this  section,  features  mentioned  will  be  located  with  respect  to  the 
vehicle,  i.e.  left  will  refer  to  the  Port  side  if  the  Argo,  while  right  will  refer  to  its  Starboard 
side. 

3.2.1  Day  1:  Afternoon  and  evening 

The  first  set  of  static  trials  data  was  acquired  on  the  15th  of  October  2008,  in  the  afternoon  and 
in  the  evening.  Most  of  the  datasets  were  acquired  when  the  sun  was  above  the  horizon,  except 
for  one,  acquired  just  after  sunset.  The  wind  was  quite  strong,  and  it  affected  significantly 
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Figure  3.1:  Static  trial  setup  seen  from  above 


Object  name 

X  (cm) 

Y  (cm) 

Diam. 

(cm) 

Height 

(cm) 

origin 

Supporting  pole  of  the  frame 
on  the  left  side  of  Argo 

0 

0 

1 

Centre  of  Argo  sensor  frame 

190 

-293 

185 

2 

Port  front  wheel  of  Argo 

112 

-202 

3 

Starboard  front  wheel  of  Argo 

269 

-202 

4 

Supporting  pole  of  the  frame 
on  the  right  side  of  the  Argo 

431 

0 

5 

Tree 

108 

252 

5 

(1) 

6 

Laser  pole 

-23 

295 

175 

7 

Radar  reflector  on  the  top  of 
a  pole 

88 

321 

114 

(2)  (3) 

8 

Laser  pole 

440 

364 

175 

9 

Two  plastic  boxes  on  top  of 
each  other:  First  box 

117.. .187 

567.. .609 

33 

Second  plastic  box 

117.. .147 

578.. .598 

33.. .67 

10 

Brick  tower 

26.. .51 

672. ..695 

100 

11 

Radar  reflector  on  the  ground 

249 

780 

29 

(3) 

12 

Canister 

315. ..342 

758.. .786 

45 

13 

Table  standing  on  its  side 

98.. .190 

861 

122 

14 

Supporting  pole  of  the  frame 
on  the  left  back  side 

0 

930 

(1)  The  branch  is  at  the  height  of  90cm.  The  foliage  of  the  tree  reaches  about  120cm  to  the  right. 

(2)  The  radar  reflector  is  hanging  so  that  the  top  of  it  is  on  the  top  of  the  supporting  pole. 

(3)  Note  that  these  radar  reflectors  are  present  in  the  test  area  only  for  datasets  number  24  to  26. 


Table  3.1:  Elements  present  in  the  static  trial  setup 
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Figure  3.2:  Photo  of  the  static  trial  area  (Datasets  01  to  24) 
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dust  and  smoke  spreading.  The  wind  was  mainly  blowing  from  the  left  with  respect  to  the 
vehicle. 

01-02  -  Clear  conditions 

The  first  two  datasets  were  acquired  in  clear  conditions,  without  any  artificially  created  dust, 
smoke  or  rain.  In  the  first  dataset  the  frame  rate  of  the  color  camera  was  10  frames  per 
second,  and  in  the  second  one  the  frame  rate  was  15  frames  per  second. 


Dataset  name:  01-StaticClear-Videol0fps 


Unix 

UTC 

AEDT 

Start 

1224050945.437 

06:09:05.437 

15:09:05.437 

End 

1224051090.447 

06:11:30.447 

15:11:30.447 

Duration 

145.010  seconds 

Dataset  name:  02-StaticClear-Videol5fps 


Unix 

UTC 

AEDT 

Start 

1224051487.381 

06:18:07.381 

15:18:07.381 

End 

1224051619.116 

06:20:19.116 

15:20:19.116 

Duration 

131.735  seconds 

03  -  Clear  conditions  with  human 

This  dataset  was  acquired  in  clear  conditions.  A  human  (intentionally)  is  walking  through 
the  area. 


Dataset  name:  03-StaticClear-Human 


Unix 

UTC 

AEDT 

Start 

1224052418.386 

06:33:38.386 

17:33:38.386 

End 

1224052519.662 

06:35:20.662 

17:35:20.662 

Duration 

101.276  seconds 

04  -  Light  dust 

In  this  dataset,  an  assistant  blew  dust  from  a  pile  that  was  located  on  the  left,  out  of  the  test 
area.  The  dust  was  carried  by  wind  from  left  to  right  with  respect  to  the  sensors.  The  dust 
cloud  mainly  occurred  between  the  sensors  and  the  test  area.  The  dust  density  was  relatively 
low.  The  dataset  started  and  ended  in  clear  conditions. 


Dataset  name:  04-StaticLightDust 


Unix 

UTC 

AEDT 

Start 

1224053469.229 

06:51:09.229 

17:51:09.229 

End 

1224053602.855 

06:53:23.855 

17:53:23.855 

Duration 

133.626  seconds 

CHAPTER  3.  DATA  SETS 


23 


Figure  3.3:  Human  walking  in  the  test  area  during  a  static  test  (Dataset  03) 
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Figure  3.4:  Static  test  with  light  dust  (Dataset  04) 


CHAPTER  3.  DATA  SETS 


25 


05  -  Heavy  dust 

As  previously,  in  this  dataset  an  assistant  blew  dust  from  a  pile  that  was  located  on  the  left, 
out  of  the  test  area.  The  dust  was  carried  by  the  wind  from  left  to  right  with  respect  to  the 
sensors,  and  it  moved  between  the  sensors  and  the  test  area.  The  dust  cloud  was  denser  than 
before.  The  dataset  started  and  ended  in  clear  conditions. 

Note  that  the  lasers  and  radar  data  start  14  to  18  seconds  later  than  the  other  sensors. 


Dataset  name:  05-StaticHeavyDust 


Unix 

UTC 

AEDT 

Start 

1224054044.006 

07:00:44.006 

18:00:44.006 

End 

1224054110.171 

07:01:50.171 

18:01:50.171 

Duration 

66.165  seconds 

06  -  Light  dust  with  human 

As  in  the  two  previous  cases,  an  assistant  blew  dust  from  a  pile  that  was  located  on  the  left 
of  the  test  area.  The  dust  was  carried  by  wind  from  left  to  right.  The  dust  cloud  mainly 
occurred  between  the  sensors  and  the  test  area.  The  dust  density  was  relatively  low.  A  human 
was  walking  around  the  test  area.  The  dataset  started  and  ended  in  clear  conditions. 


Dataset  name:  06-StaticLightDust-] 

Human 

Unix 

UTC 

AEDT 

Start 

1224055857.924 

07:30:58.924 

18:30:58.924 

End 

1224055992.320 

07:33:12.320 

18:33:12.320 

Duration 

134.396  seconds 

07  -  Smoke 

An  assistant  held  a  smoke  bomb  in  the  left  of  the  test  area.  The  smoke  moved  almost  entirely 
between  the  sensors  and  the  test  area.  The  dataset  started  and  ended  in  clear  conditions. 


Dataset  name:  07-StaticSmoke 


Unix 

UTC 

AEDT 

Start 

1224056457.502 

07:40:58.502 

18:40:58.502 

End 

1224056543.290 

07:42:23.290 

18:42:23.290 

Duration 

85.788  seconds 

08  -  Heavy  rain 

The  sprinklers  were  used  to  create  heavy  rain.  Wind  from  the  left  biased  the  rain  towards 
the  right,  and  therefore  the  left  part  of  the  test  area  had  less  rain  than  the  right  part.  Rain 
was  present  during  the  whole  dataset. 


Dataset  name:  08-StaticHeavyRain 


Unix 

UTC 

AEDT 

Start 

1224056989.625 

07:49:50.625 

18:49:50.625 

End 

1224057123.862 

07:52:04.862 

18:52:04.862 

Duration 

134.237  seconds 
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Figure  3.5:  Static  test  with  smoke(Dataset  07) 
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09  -  Heavy  rain  with  human 

As  before,  the  sprinklers  were  used  to  create  heavy  rain.  A  human  was  walking  around  the 
test  area.  Wind  from  the  left  biased  the  rain  towards  right  again.  Rain  was  present  during 
the  whole  dataset. 


Dataset  name:  09-StaticHeavyRain-Human 


Unix 

UTC 

AEDT 

Start 

1224057199.911 

07:53:20.911 

18:53:20.911 

End 

1224057280.261 

07:54:40.261 

18:54:40.261 

Duration 

80.350  seconds 

10  -  Light  rain 

The  sprinklers  were  used  to  create  lighter  rain.  As  in  the  previous  cases,  wind  from  the  left 
biased  the  rain  towards  right  with  respect  to  the  sensors.  The  rain  was  created  during  the 
whole  dataset. 


Dataset  name:  10-StaticLightRain 


Unix 

UTC 

AEDT 

Start 

1224057494.661 

07:58:15.661 

18:58:15.661 

End 

1224057652.537 

08:00:53.537 

19:00:53.537 

Duration 

157.876  seconds 

11  -  Clear  conditions  after  rain 

This  dataset  was  acquired  right  after  the  rain  datasets,  with  the  sprinklers  turned  off.  Conse¬ 
quently,  all  the  objects  in  the  test  area  were  wet,  and  a  few  drops  of  water  were  occasionally 
still  falling  from  the  top  of  the  frame.  The  sun  was  very  low  but  still  above  the  horizon  during 
the  acquisition  of  this  dataset. 


Dataset  name:  11-StaticAfterRainEvening 


Unix 

UTC 

AEDT 

Start 

1224057998.295 

08:06:38.295 

19:06:38.295 

End 

1224058157.685 

08:09:18.685 

19:09:18.685 

Duration 

159.390  seconds 

12  -  Clear  conditions  after  rain  and  sunset 

This  dataset  was  acquired  just  after  sunset.  There  is  still  reasonable  light,  but  the  sun  is 
already  below  the  horizon.  This  dataset  was  acquired  shortly  after  the  rain  datasets  as  well, 
so  all  the  objects  in  the  test  area  were  still  wet,  with  also  the  possibility  of  having  a  few  drops 
of  water  still  falling.  Note  that  the  lasers  data  logs  stop  about  88  seconds  before  the  rest  of 
the  data. 


Dataset  name:  12-StaticClearAfterRainAfterSunset 


Unix 

UTC 

AEDT 

Start 

1224058839.207 

08:20:39.207 

19:20:39.207 

End 

1224058972.002 

08:22:52.002 

19:22:52.002 

Duration 

132.795  seconds 
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3.2.2  Day  2:  Morning  and  midday 

The  second  set  of  static  trials  was  realized  on  the  16th  of  October  2008,  starting  in  the 
morning  and  lasting  until  midday.  In  all  of  the  datasets  sun  was  high  in  the  sky.  There  was 
much  less  wind  than  during  the  first  day,  and  its  direction  varied. 

14  -  Clear 

This  dataset  was  acquired  in  clear  conditions,  without  any  artificially  created  dust,  smoke  or 
rain. 


Dataset  name:  14-StaticMorningClear 


Unix 

UTC 

AEDT 

Start 

1224112428.048 

23:13:48.048 

10:13:48.048 

End 

1224112600.636 

23:16:41.636 

10:16:41.636 

Duration 

172.588  seconds 

15  -  Heavy  dust 

An  assistant  blew  dust  from  a  pile  that  was  located  west  of  the  test  area.  The  dust  was 
carried  by  wind  from  left  to  right  with  respect  to  the  sensors.  The  dust  cloud  moved  a  bit 
to  south-east,  and  therefore  the  north-eastern  corner  of  the  area  was  not  completely  covered 
with  dust.  The  dust  density  was  high.  The  dataset  started  and  ended  in  clear  conditions. 
The  Figure  3.6  shows  the  dust  cloud. 


Dataset  name:  15-StaticMorningHeavyDust 


Unix 

UTC 

AEDT 

Start 

1224113347.161 

23:29:07.161 

10:29:07.161 

End 

1224113448.576 

23:30:49.576 

10:30:49.576 

Duration 

101.415  seconds 

16  -  Very  light  dust 

An  assistant  blew  dust  from  a  dusty  road  west  of  the  test  area.  Part  of  the  dust  was  carried 
by  wind  from  left  to  right  with  respect  to  the  sensors.  The  dust  cloud  was  very  thin  when  it 
reached  the  test  area.  The  dataset  started  and  ended  in  clear  conditions. 


Dataset  name:  16-StaticMorningVeryLightDust 


Unix 

UTC 

AEDT 

Start 

1224114064.835 

23:41:05.835 

10:41:05.835 

End 

1224114139.801 

23:42:20.801 

10:42:20.801 

Duration 

74.966  seconds 

17  -  Smoke 

An  assistant  held  a  smoke  bomb  that  generated  smoke  to  the  test  area.  The  wind  was  very 
weak,  but  strong  enough  to  carry  the  smoke  towards  the  test  area.  The  direction  of  the  wind 
changed  during  the  test.  The  assistant  was  first  standing  at  the  left  side  of  the  test  area,  then 
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Figure  3.6:  Static  test  with  heavy  dust  (Dataset  15) 
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Figure  3.7:  Static  test  with  smoke  (Dataset  17) 


he  moved  to  the  back  of  it  and  finally  to  the  right  side.  The  assistant  was  always  standing 
outside  of  the  test  area.  The  dataset  started  and  ended  in  clear  conditions  with  no  smoke. 


Dataset  name:  17-StaticMorningSmoke 


Unix 

UTC 

AEDT 

Start 

1224114471.313 

23:47:51.313 

10:47:51.313 

End 

1224114571.005 

23:49:31.005 

10:49:31.005 

Duration 

99.692  seconds 

18  -  Light  rain 

The  sprinklers  were  used  to  create  light  rain.  The  weak  wind  did  not  affect  much  the  direction 
of  the  rain.  Note  that  the  area  closer  to  the  sensors  did  not  get  as  much  rain  as  the  area 
further  away.  Besides,  the  rain  was  not  completely  uniform  in  the  area,  due  to  a  leak  in  the 
front. 


Dataset  name:  18-StaticMorningLightRain 


Unix 

UTC 

AEDT 

Start 

1224117868.591 

00:44:29.591 

11:44:29.591 

End 

1224117989.562 

00:46:30.562 

11:46:30.562 

Duration 

120.971  seconds 

CHAPTER  3.  DATA  SETS 


31 


19  -  Rain 

The  sprinklers  were  used  to  create  heavier  rain.  The  weak  wind  did  not  affect  much  the 
direction  of  the  rain. 


Dataset  name:  19-StaticMorningRain 


Unix 

UTC 

AEDT 

Start 

1224120580.504 

01:29:41.504 

12:29:41.504 

End 

1224120739.598 

01:32:20.598 

12:32:20.598 

Duration 

159.094  seconds 

20  -  Smoke 

An  assistant  held  a  smoke  bomb  that  generated  smoke  to  the  test  area.  In  this  test  the 
direction  of  the  wind  did  not  change  much.  The  assistant  was  mainly  standing  at  the  back- 
right  corner  of  the  test  area.  The  assistant’s  arm  may  have  entered  the  test  area  in  the 
beginning.  The  dataset  started  and  ended  in  clear  conditions  with  no  smoke.  As  this  dataset 
was  acquired  after  the  rain,  all  the  objects  were  wet. 


Dataset  name:  20-StaticMorningSmoke 


Unix 

UTC 

AEDT 

Start 

1224120901.096 

01:35:01.096 

12:35:01.096 

End 

1224120989.101 

01:36:29.101 

12:36:29.101 

Duration 

88.005  seconds 

21  -  Clear  conditions  after  rain  and  smoke 

This  dataset  was  acquired  after  the  smoke  and  rain  datasets.  All  the  objects  in  the  test  area 
were  wet,  and  there  might  be  some  residue  from  the  smoke. 


Dataset  name:  21-StaticMorningClearAfterRainAndSmoke 


Unix 

UTC 

AEDT 

Start 

1224121144.696 

01:39:05.696 

12:39:05.696 

End 

1224121263.788 

01:41:04.788 

12:41:04.788 

Duration 

119.092  seconds 

3.2.3  Day  2:  Morning  and  midday  -  with  added  radar  reflectors 

The  second  part  of  the  second  day’s  tests  was  done  in  the  same  area,  but  with  two  additional 
features  in  the  area:  radar  reflectors.  Also  their  positions  are  marked  in  the  figure  3.1.  The 
figure  3.9  shows  the  test  area  with  the  radar  reflectors. 

22  -  Clear 

The  reflectors  are  still  in  the  test  area.  The  dataset  was  acquired  in  clear  conditions. 
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Figure  3.8:  Static  test  with  smoke  (Dataset  20) 
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Figure  3.9:  Static  test  area  with  radar  reflectors  (Datasets  22  &  23) 
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Dataset  name:  22-StaticM 

mmingClearWithReflectors 

Unix 

UTC 

AEDT 

Start 

1224122292.159 

01:58:12.159 

12:58:12.159 

End 

1224122430.871 

02:00:31.871 

13:00:31.871 

Duration 

138.712  seconds 

23  -  Clear,  human  walking 

In  this  dataset  the  human  was  walking  around  the  test  area.  The  human  did  not  interact 
especially  with  the  radar  reflectors  but  walked  past  them. 


Dataset  name:  23-StaticMorningClearWithReflectors-Human 


Unix 

UTC 

AEDT 

Start 

1224122579.975 

02:03:00.975 

13:03:00.975 

End 

1224122682.009 

02:04:42.009 

13:04:42.009 

Duration 

102.034  seconds 

24  -  Clear,  human  walking  near  reflectors 

In  this  dataset  the  human  was  also  walking  around  the  test  area.  Unlike  for  the  previous 
dataset,  the  walking  pattern  was  related  to  the  radar  reflectors.  The  human  walked  near  the 
radar  reflectors,  first  behind  the  reflector,  then  between  the  reflector  and  the  sensors,  and 
finally,  on  the  side  of  the  reflector.  This  was  repeated  for  both  reflectors. 

Dataset  name:  24-StaticMorningClearWithReflectors-HumanNear Reflectors 


Unix 

UTC 

AEDT 

Start 

1224122950.838 

02:09:11.838 

13:09:11.838 

End 

1224123096.280 

02:11:36.280 

13:11:36.280 

Duration 

145.442  seconds 

3.2.4  Summary  of  Static  Datasets 

The  following  table  summarizes  the  conditions  for  each  of  these  datasets  taken  with  static 
vehicle. 
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Dataset 

Dust 

Smoke 

Rain 

Human 

Comment 

01-02 

Clear 

03 

X 

04-05 

X 

06 

X 

X 

07 

X 

08 

X 

09 

X 

X 

10 

X 

11 

Clear,  evening 

12 

Clear,  after  sunset 

14 

Clear,  morning 

15-16 

X 

17 

X 

18  &  19 

X 

20 

X 

21 

22 

with  radar  reflectors 

23-24 

X 

with  radar  reflectors 

3.3  Dynamic  tests 

In  the  dynamic  tests,  the  vehicle  was  driving  around  different  areas  and  acquiring  data  from 
the  environment.  Simulated  environmental  conditions  such  as  dust,  rain  and  smoke,  were  also 
created  for  some  datasets.  Unlike  for  the  static  datasets,  the  rain  was  produced  with  mobile 
equipment. 

3.3.1  Open  area 

The  tests  in  this  section  were  realized  in  an  open  area,  on  mostly  flat  ground.  The  soil  on  the 
ground  is  very  dusty,  which  means  that  rapid  movements  of  the  vehicle  produce  thick  clouds 
of  dust  without  any  external  input.  On  the  northern  side  of  the  area  is  a  shed  with  metal 
walls.  Next  to  the  shed,  there  is  a  fence.  Another  fence  is  located  on  the  south-western  side 
of  the  area.  Both  fences  consist  of  barbed  wire  and  wooden  posts.  The  area  is  bounded  by 
an  unpaved  road  on  the  eastern  side.  Figure  3.10  shows  an  aerial  image  of  the  area.  This  test 
area  is  on  the  left  side  of  the  image.  Figure  3.11  shows  a  photo  of  the  area. 

29  -  Clear  conditions  during  day 

This  dataset  was  acquired  during  daytime.  The  vehicle  was  driving  around  the  area  avoiding 
sharp  turns  that  would  have  caused  much  dust. 


Dataset  name:  29-DynamicDayTriangleClear 


Unix 

UTC 

AEDT 

Start 

1224198733.114 

23:12:13.114 

10:12:13.114 

End 

1224199111.326 

23:18:31.326 

10:18:31.326 

Duration 

378.212  seconds 
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Figure  3.10:  Aerial  image  of  the  open  area  (on  the  left  side  of  the  path)  and  the  houses  area 
(on  the  right  side  of  the  path) 


Figure  3.11:  Photo  of  the  open  area  (Datasets  25  to  32) 
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Figure  3.12:  Dynamic  test  in  the  open  area  with  dust  (Datasets  30  &  31) 

30-31  -  Dust  during  day 

These  datasets  were  acquired  during  daytime.  The  vehicle  was  driving  around  the  area  while 
an  assistant  produced  the  dust.  The  ground  of  the  area  is  very  dusty,  so  the  dust  was  produced 
just  by  pointing  the  blower  to  the  ground.  The  assistant  needed  to  walk  around  the  test  area. 
They  can  be  seen  in  the  dataset. 


Dataset  name:  30-DynamicDayTriangleDust 


Unix 

UTC 

AEDT 

Start 

1224199788.106 

23:29:48.106 

10:29:48.106 

End 

1224199986.155 

23:33:06.155 

10:33:06.155 

Duration 

198.049  seconds 

Dataset  name:  31-DynamicDayTriangleMoreDust 


Unix 

UTC 

AEDT 

Start 

1224200313.353 

23:38:33.353 

10:38:33.353 

End 

1224200500.152 

23:41:40.152 

10:41:40.152 

Duration 

186.799  seconds 

32  -  Clear  conditions  after  dust  on  day 

This  dataset  was  acquired  after  the  datasets  with  dust.  The  objects  in  the  area  are  probably 
more  dusty  than  in  the  earlier  dataset  in  clear  conditions. 
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Dataset  name:  32-DynamicDayTriangleC] 

.earAfterDust 

Unix 

UTC 

AEDT 

Start 

1224201093.019 

23:51:33.019 

10:51:33.019 

End 

1224201271.635 

23:54:32.635 

10:54:32.635 

Duration 

178.616  seconds 

25-27  -  Clear  conditions  at  night  with  external  lights  on 

These  datasets  were  acquired  at  nighttime.  The  sun  had  set  completely,  so  all  the  light  was 
artificially  created.  A  car  was  parked  in  the  test  area.  The  headlights  of  the  car  were  on  and 
pointing  towards  the  area  where  the  test  vehicle  moved.  The  vehicle’s  own  headlights  also 
illuminated  the  area  in  front  of  it.  Note  that  in  dataset  27  the  door  of  the  shed  was  open 
with  the  internal  light  of  the  building  on.  This  can  be  seen  in  the  images  of  the  camera. 


Dataset  name:  25-DynamicNightClearTriangleWithCarLights 


Unix 

UTC 

AEDT 

Start 

1224158167.214 

11:56:07.214 

22:56:07.214 

End 

1224158524.566 

12:02:05.566 

23:02:05.566 

Duration 

357.352  seconds 

Dataset  name:  27-DynamicNig 


htClearTriangleWithCarLights2 


Unix 

UTC 

AEDT 

Start 

1224159874.355 

12:24:34.355 

23:24:34.355 

End 

1224160153.568 

12:29:14.568 

23:29:14.568 

Duration 

279.213  seconds 

26-28  -  Clear  conditions  at  night  without  external  lights 

These  datasets  were  acquired  at  nighttime,  the  only  artificial  light  coming  from  the  vehicle’s 
own  headlights. 


Dataset  name:  26-DynamicNightClearTriangleNoCarLights 


Unix 

UTC 

AEDT 

Start 

1224158859.005 

12:07:39.005 

23:07:39.005 

End 

1224159161.470 

12:12:41.470 

23:12:41.470 

Duration 

302.465  seconds 

Dataset  name:  28-DynamicNightClearTriangleNoCarLights2 


Unix 

UTC 

AEDT 

Start 

1224160333.789 

12:32:14.789 

23:32:14.789 

End 

1224160606.918 

12:36:47.918 

23:36:47.918 

Duration 

273.129  seconds 

Summary 

The  following  table  summarizes  the  conditions  for  each  of  these  datasets  taken  in  the  open 


area. 
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Dataset 

Dust 

Daytime 

Night  w. 
Ext.  Light 

Night  no 
Ext.  Light 

Comment 

29 

X 

Clear 

30-31 

X 

X 

32 

X 

After  dust 

25  &  27 

X 

Ext.  car  lights 

26  &  28 

X 

3.3.2  Area  with  houses 

This  is  an  area  with  three  wooden  buildings.  A  long  building  is  standing  in  the  southern  side 
of  the  area.  Two  smaller  ones  are  on  the  northern  side.  The  area  is  bounded  by  a  fence.  This 
area  can  be  seen  on  the  right  side  of  the  aerial  image  in  figure  3.10. 

33  -  Clear  conditions  without  humans 

This  dataset  was  acquired  in  the  daytime.  The  vehicle  was  driving  around  the  area  with 
houses  (see  figure  3.13). 


Dataset  name:  33-DynamicDayHousesClear 


Unix 

UTC 

AEDT 

Start 

1224201950.093 

00:05:50.093 

11:05:50.093 

End 

1224202213.225 

00:10:13.225 

11:10:13.225 

Duration 

263.132  seconds 

34  -  Clear  conditions,  human  walking  around 

This  dataset  was  acquired  at  daytime.  The  vehicle  was  driving  around  the  same  area  as 
before  and  in  similar  conditions.  However,  in  addition  to  the  previous  dataset,  a  human  was 
walking  around  during  the  test. 


Dataset  name:  34-DynamicDayHouses-Human 


Unix 

UTC 

AEDT 

Start 

1224202880.040 

00:21:20.040 

11:21:20.040 

End 

1224203087.626 

00:24:48.626 

11:24:48.626 

Duration 

207.586  seconds 

3.3.3  Area  with  trees  and  water 

This  is  an  area  next  to  a  lake.  On  the  southern  side  of  the  area  there  is  a  small  eucalyptus 
forest.  A  photo  of  the  area  is  shown  in  figure  3.14. 

35  -  Clear  conditions 

This  dataset  was  acquired  at  daytime.  The  vehicle  was  driving  around  the  area. 


CHAPTER  3.  DATA  SETS 


40 


Figure  3.13:  Dynamic  test  around  the  houses  (Datasets  33  &  34) 
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Figure  3.14:  Photo  of  the  area  with  trees  and  a  lake  (Datasets  35  to  40) 
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Dataset  name:  35-DynamicDayDamClear 


Unix 

UTC 

AEDT 

Start 

1224216067.282 

04:01:07.282 

15:01:07.282 

End 

1224216412.990 

04:06:53.990 

15:06:53.990 

Duration 

345.708  seconds 

36-37  -  Dust 

These  datasets  were  acquired  during  daytime.  An  assistant  produced  the  dust  by  pointing 
the  blower  to  the  ground.  It  was  not  as  dusty  as  in  the  open  area,  and  therefore  there  was 
less  dust  in  this  area.  The  assistant  had  to  move  a  little  in  order  to  create  the  dust  in  front 
of  the  vehicle.  The  figure  3.15  shows  a  photo  of  the  actual  situation. 


Dataset  name:  36-DynamicDayDamDust 


Unix 

UTC 

AEDT 

Start 

1224216779.827 

04:13:00.827 

15:13:00.827 

End 

1224216962.271 

04:16:02.271 

15:16:02.271 

Duration 

182.444  seconds 

Dataset  name:  37-DynamicDayDamDust2 


Unix 

UTC 

AEDT 

Start 

1224217352.224 

04:22:32.224 

15:22:32.224 

End 

1224217563.883 

04:26:04.883 

15:26:04.883 

Duration 

211.659  seconds 

38  -  Smoke 

This  dataset  was  acquired  during  daytime.  An  assistant  held  a  smoke  bomb.  He  tried  to 
stay  in  a  position  where  the  smoke  went  towards  the  vehicle,  therefore  they  needed  to  move 
a  little.  The  figure  3.16  shows  a  photo  of  the  situation.  The  photo  was  taken  by  the  assistant 
holding  the  smoke  bomb. 


Dataset  name:  38-DynamicDayDamSnroke 


Unix 

UTC 

AEDT 

Start 

1224217939.781 

04:32:20.781 

15:32:20.781 

End 

1224218021.286 

04:33:41.286 

15:33:41.286 

Duration 

81.505  seconds 

39  -  Rain 

This  dataset  was  acquired  at  daytime.  An  assistant  created  a  “water  curtain”  in  front  of  the 
vehicle  with  a  hose  spraying  water.  Again,  the  assistant  needed  to  move  in  order  to  keep  the 
water  in  front  of  the  vehicle.  The  figure  3.17  shows  a  photo  of  the  situation. 


Dataset  name:  39-DynamicDayDamRain 


Unix 

UTC 

AEDT 

Start 

1224229665.084 

07:47:45.084 

18:47:45.084 

End 

1224229783.877 

07:49:44.877 

18:49:44.877 

Duration 

118.793  seconds 
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Figure  3.15:  Dynamic  test  around  the  lake  with  dust  (Datasets  36  to  37) 
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Figure  3.16:  Dynamic  test  around  the  lake  with  smoke  (Dataset  38) 
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Figure  3.17:  Dynamic  test  around  the  lake  with  simulated  rain  (Dataset  39) 


40  -  Clear,  sun  low  in  the  sky 

The  dataset  was  acquired  in  the  evening,  just  before  the  sunset.  In  this  dataset  there  were 
no  artificially  created  environmental  conditions  and  no  people  moving. 


Dataset  name:  40-DynamicDayDamClear-SunLow 


Unix 

UTC 

AEDT 

Start 

1224230071.163 

07:54:31.163 

18:54:31.163 

End 

1224230243.984 

07:57:24.984 

18:57:24.984 

Duration 

172.821  seconds 

Summary 

The  following  table  summarizes  the  conditions  for  each  of  these  datasets  taken  in  this  area 
with  trees  and  lake. 


Dataset 

Dust 

Smoke 

Rain 

Comment 

35 

Clear 

36-37 

X 

38 

X 

39 

X 

40 

Sun  low 
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3.3.4  Summary  of  Dynamic  Datasets 

The  following  table  shows  a  summary  of  all  conditions  covered  in  all  dynamic  datasets.  It 
does  not  precise  the  area  in  which  the  dataset  was  taken  though,  this  precision  can  be  found 
directly  in  the  appropriate  section.  The  default  configuration  is  at  daytime  (i.e.  the  Night 
is  only  precised  where  appropriate). 


Dataset 

Dust 

Smoke 

Rain 

Human 

Night 

Comment 

25  to  28 

X 

Clear,  at  night 

29  &  32 

Clear 

30  &  31 

X 

33 

Clear,  Houses  area 

34 

X 

Houses  area 

35 

Clear 

36  &  37 

X 

38 

X 

39 

X 

40 

Clear 

3.4  Calibration  Datasets 

3.4.1  Cameras 

The  data  used  to  realize  the  calibrations  concerning  the  Visual  camera  and  the  IR  camera  can 
be  found  respectively  in  the  directories  VisualCameraCalibration  and  IRcameraCalibration, 
which  are  both  organised  as  follow.  They  contain  the  following  directories: 

•  LaserHorizontal 

•  LaserPort 

•  LaserStarboard 

•  LaserVertical 

•  VideoVisual  or  VideoIR  as  appropriate 

which  content  is  as  described  for  the  previous  datasets  (see  section  2.2). 

In  an  additional  directory,  named  Calibration,  the  following  files  and  directories  can  be 
found: 

•  Calib_Results  .m  and  CalibJResults .mat  are  the  files  exported  by  the  Matlab  Cali¬ 
bration  Toolbox,  contains  all  the  calibration  parameters  estimated. 

•  Images  is  a  directory  containing  the  images  that  were  used  for  the  camera  calibration 
process,  named  with  successive  numbers  starting  by  1,  for  convenience  when  loading 
them  in  Matlab. 

•  matlabAsciiLaserData  is  a  directory  containing  the  ascii  descriptions  of  all  laser  data 
in  files  formatted  to  be  suitable  for  Matlab,  for  convenience. 
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•  VideoLogAsciiCalibration.txt  is  a  text  file  figuring  the  timestamps  for  all  images  in 
Images,  the  number  of  line  in  this  file  corresponding  to  the  number  of  the  image  as  it  is 
named  in  Images  (e.g.  the  timestamp  corresponding  to  the  image  named  image002.bmp 
can  be  found  at  the  line  number  2  of  VideoLogAsciiCalibration.txt). 

The  images  in  these  datasets  show  a  chess  board  exposed  with  various  orientations  in 
space,  and  at  various  distances.  Note  that  these  chess  boards  are  different  for  the  Visual 
camera  and  the  IR  camera.  The  size  of  the  Black  and  White  squares  of  these  chess  board  are 
the  following: 

•  for  the  IR  camera:  114.8mm  on  both  sides. 

•  for  the  Visual  camera:  74.9mm  on  the  axis  left-right  as  it  can  be  seen  in  the  images 
and  74.7 mm.  on  the  axis  corresponding  to  the  direction  up-down. 

3.4.2  Range  Sensors  (Lasers  and  Radar) 

The  data  used  for  the  range  sensors  calibration  can  be  found  in  the  directory  named: 

RangeSensorsCalibration 

It  is  organized  exactly  as  the  regular  datasets  that  were  presented  before  (except  that  it 
does  not  contain  the  directories  RadarSpectrum  and  Payload).  Data  from  all  sensors  were 
collected  in  the  so-called  open  area,  with  four  vertical  poles  standing  on  a  flat  ground.  These 
special  features  of  known  geometry  as  well  as  the  vertical  wall  of  the  shed  and  the  flat  part 
of  the  ground  were  used  to  extract  relevant  data  for  the  calibration  process. 


Chapter  4 

Preliminary  Analysis 


This  chapter  proposes  in  its  first  section  a  preliminary  analysis  of  the  performance  of  the 
sensors  considered  in  this  work.  It  will  focus,  as  an  illustrative  example,  on  the  case  of  the 
presence  of  dust  or  smoke.  In  the  second  section,  we  propose  some  ideas  to  tackle  the  issue 
of  challenging  environments  when  using  sensors  for  obstacle  detection  or  terrain  modeling. 

4.1  Case  Study 

Lasers  are  extremely  affected  by  dust  and  smoke.  More  precisely,  a  cloud  of  dust  or  smoke  is 
almost  seen  as  an  actual  obstacle.  Thus,  a  basic  analysis  of  the  data  provided  by  them  might 
lead  to  false  detection  of  large  obstacles.  This  is  all  the  more  true  as  the  SICK  lasers  only 
provide  the  information  concerning  the  first  return  1 . 

The  radar  operates  at  mm  wavelengths,  which  makes  the  size  of  dust  and  smoke  particles 
relatively  much  smaller,  giving  radar  waves  more  penetration.  Consequently,  it  is  much  less 
affected  by  dust  or  smoke,  except  for  a  slight  increase  of  the  level  of  noise  in  the  data,  and 
lower  reflectivities  for  the  returns.  The  following  figures  illustrate  that  statement. 

Figure  4.1  and  4.2  show  all  the  range  values  returned  by  the  LaserHorizontal  and  the 
radar  respectively,  for  a  static  test  in  clear  conditions  (dataset  02).  All  scans  made  during 
the  complete  duration  of  the  dataset  collection  are  drawn  in  these  figures.  The  angle  range 
corresponds  to  what  is  perceived  in  the  test  area:  the  first  and  last  notable  feature  on  the 
left  and  right  of  the  graph  are  respectively  the  left  and  right  poles  of  the  trial  frame  (objects 
named  origin  and  1  in  the  table  in  section  3.2).  Note  that  the  laser,  providing  much  more 
precise  (raw)  range  measurements  than  the  radar,  detects  ah  the  objects  that  are  located  in 
its  held  of  view,  while  the  radar  detects  only  the  main  ones  and  provides  noiser  data. 

Figure  4.3  shows  the  same  measurements  from  the  laser  and  radar  in  the  presence  of 
dust  (dataset  05).  We  can  see  that  dust  generates  random  points  in  the  laser  scans,  located 
between  the  vehicle  and  the  actual  position  of  the  obstacle. 

Figure  4.4  shows  that  the  results  are  similar  in  the  presence  of  smoke:  the  laser  sees  it  as 
an  obstacle  whereas  the  radar  data  are  not  significantly  affected. 

On  figure  4.5  we  can  have  a  preliminary  view  of  the  effect  of  rain.  The  laser  data  are 
actually  not  particularly  affected,  except  for  a  few  specific  points,  which  might  be  due  to 
reflection  effects  on  wet  objects  surfaces.  This  case  warrants  further  investigation. 

home  other  lasers  also  provide  information  about  a  possible  additional  return.  This  might  at  least  lead  to 
some  suspicion  on  the  features  perceived  with  a  significant  difference  between  these  two  returns. 
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(a)  Dots  display  (b)  Lines  display 

Figure  4.1:  Range  returned  by  LaserHorizontal  over  angle,  for  static  test  in  clear  conditions 
(Dataset  02);  displayed  in  dots  in  (a)  and  lines  in  (b) 


Angle  (degrees;  Angle  (degrees; 


(a)  Dots  display  (b)  Lines  display 

Figure  4.2:  Range  returned  by  the  radar  (RadarRangeBearing)  over  angle,  for  static  test  in 
clear  conditions  (Dataset  02);  displayed  in  dots  in  (a)  and  lines  in  (b) 
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(a)  LaserHorizontal  (b)  Radar 

Figure  4.3:  Range  returned  by  the  laser  Horizontal  and  the  radar  (RadarRangeBearing)  over 
angle,  for  static  test  with  heavy  dust  (Dataset  05). 


(a)  LaserHorizontal  (b)  Radar 

Figure  4.4:  Range  returned  by  the  laserHorizontal  and  the  radar  over  angle,  for  static  test 
with  smoke  (Dataset  07). 
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Angle  (degrees] 


(a)  LaserHorizontal  (b)  Radar 

Figure  4.5:  Range  returned  by  the  laserHorizontal  and  the  radar  over  angle,  for  static  test 
with  rain  (Dataset  08).  The  Laser  data  is  here  drawn  with  lines  for  an  easier  identification  of 
the  special  reflection  effects  due  to  the  presence  of  water  on  the  objects  (compare  with  figure 
4.1  (b)). 


Note  that  besides  the  lasers,  both  visual  and  thermal  camera  images  are  affected  by  dust 
(and  smoke),  but  the  effect  is  lower  on  the  infra-red  data,  as  infra-red  waves  have  a  higher 
penetration  power. 

4.2  Discussion 

To  avoid  the  problem  of  false  obstacles  created  by  conditions  such  as  presence  of  dust  or  smoke, 
and  increase  the  integrity  of  sensor  data  in  general,  one  can  benefit  from  the  redundancy  of 
sensors  on  a  vehicle.  This  redundancy  can  be  of  different  kinds.  Let  us  consider  a  particular 
set  of  sensors. 

•  if  these  sensors  are  identical,  i.e.  they  measure  the  same  data  (e.g.  range)  using  the 
same  process  and  the  same  physical  characteristics  (e.g.  several  2D  Sick  Lasers),  when 
their  measurements  overlap  they  may  be  directly  compared  to  detect  major  failures 
only,  such  as  a  breakdown. 

•  if  the  sensors  measure  the  same  type  of  data  (e.g.  range),  but  in  a  different  way  (e.g.  a 
laser  scanner  and  a  radar  scanner,  operating  at  different  wavelengths),  the  comparison 
of  their  measurements  may  provide  valuable  information  about  the  environment,  to  take 
an  appropriate  decision  and  be  able  to  keep  sensing  abilities  in  an  environment  which 
is  challenging  for  one  type  of  sensor.  For  example:  the  radar  waves  penetrate  dust  and 
smoke  much  more  easily  than  the  laser  ones,  thus  we  know  that  in  the  presence  of  dust 
the  radar  will  provide  more  accurate  range  measurement  (it  is  the  opposite  in  clear 
conditions). 

•  if  the  sensors  measure  different  kinds  of  data  (e.g  a  laser  scanner  and  a  colour  camera), 
a  comparison  might  still  be  made  at  a  higher  level  of  abstraction,  for  example  after 
classification  of  pieces  of  the  terrain  in  classes  such  as  obstacles  or  flat  terrain. 
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An  example  of  the  second  case  mentioned  above  is  a  preliminary  study  realized  by  James 
Underwood  at  ACFR  to  filter  dust  in  range  measurements  provided  by  a  laser  and  a  radar. 
By  comparing  these  measurements  of  the  same  area,  knowing  a  model  of  the  uncertainties 
involved,  it  is  possible  to  identify  when  the  error  between  data  from  these  two  sensors  is  too 
high,  which  means  that  the  data  should  not  be  validated.  In  this  study,  as  only  two  sensors  are 
used,  it  is  not  possible  to  determine  which  one  is  wrong.  Consequently,  the  only  reasonable 
decision  is  to  ignore  both  types  of  data  (see  figure  4.6).  If  an  additional  sensor,  with  different 
characteristics,  is  available,  a  more  “informative”  decision  can  be  made  if,  for  example,  data 
from  two  sensors  match  while  data  from  the  third  one  shows  a  level  of  discrepancy. 


(a)  Raw  Laser  Data  (b)  Filtered  Laser  Data 


Figure  4.6:  3D  points  returned  by  a  Laser  Range  Scanner  during  a  dynamic  test  in  presence 
of  dust:  before  (a)  and  after  (b)  filtering.  The  green  object  visible  in  both  images  is  a  static 
car. 
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